A PBX (private branch exchange) provides interconnections among internal telephone lines that are connected to telephone instruments at a single facility (such as a law office). The PBX also interconnects the internal telephone lines to a smaller number of external telephone lines (also called “trunks”) of a telephone company. Such PBXs provide a number of features of the type described in, for example, “DEFINITY Communications System, Generic 1 and Generic 3 and System 75, 8410 Voice Terminal User's Guide,” pages 5–8, 1994, published by AT&T GBCS Documentation Development, Middletown, N.J., 07748-1998.
There is a growing trend towards audio communications taking place over packet-switched networks, such as the Internet, instead of directly on the telephone network (that provides only circuit switching and is sometimes called “public switched telephone network (PSTN)”). Such audio communications can be facilitated by various types of devices such as: (1) specialized PBXs (also called “packet-switching PBXs”) that directly connect to packet-switched networks, (2) gateways that connect circuit-switching devices to packet-switched networks and (3) software tools that connect personal computers to packet-switched networks. One example of a packet-switching PBX, as seen in FIG. 1, is described in “Intranet and IP-Based UnPBXs,” Chapter 7, pages 7–16 to 7–22, in the book entitled “the UnPBX” edited by Edwin Margulies, Flatiron Publishing, Inc. 1997.
In this example, the packet-switching PBX includes one or more telephony switches 1 and 2, each of which has twelve ports that can be connected either to internal telephone lines or to external telephone lines. In addition, each of telephony switches 1 and 2 includes a digital port that is connected to an Ethernet 3 for communication therebetween. For example, if telephone instrument 4 needs to be connected to telephone instrument 5, switch 1 routes the call via Ethernet 3 to switch 2. Information carried by any call routed over Ethernet 3 is divided into a number of portions; each portion placed in a packet (such as a Universal Datagram Protocol (UDP) packet conforming to the Transmission Control Protocol (TCP) Internet Protocol (IP) used over the Internet) that is transmitted between switches 1 and 2. TCP and UDP both travel on top of the IP. TCP is a session- and connection-oriented protocol. UDP carries packets with nothing in the UDP portion itself to identify any stream, or connection.
An example of a conventional gateway for circuit-switching PBXs is an Internet Telephony Server which includes a PSTN interface board 11, as seen in FIG. 2, for connection to telephone lines (T1/E1/analog) of a PBX, and a Digital Signal Processor (DSP) card 12 that performs voice compression and/or fax processing and generates packets, and the packets are sent to an Ethernet 13 via an Ethernet card 14.
One example of a software tool for use in a personal computer is an audio conferencing tool described in “vat—LBNL Audio Conferencing Tool”, published May 1996 and available at wwwnrg-ee-lbl-gov%vat. The packets generated by this tool conform to the Real-Time Transport Protocol (RTP) as described in “RTP: A Transport Protocol for Real-Time Applications”, Network Working Group, January 1996, which is available from the Internet Engineering Task Force (IETF) website as Request for Comment (RFC) 1889, www-ietf-org%rfc%rfc1889.txt?number=1889. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video, or simulation data, over multicast or unicast network services.
Data packets sent on an RTP stream carry only a hint as to which call the data packets relate to. In RTP packets, the hint comes in the form of 32 bit (i.e., 4 byte) identifiers which help locate the generator of the data in the packet. However, as the identifier is not centrally generated, cases arise where two sources generate the same identifier, and thus ‘collide’ on the use of a particular pattern in these 32 bits. In this case, the sources simply choose a new identifier, and the recipients are left to figure out what has happened. RTP itself does not contain a mechanism to keep the identifiers unique.
Classical RTP requires that either all ports of the firewall be opened or that the firewall recognize that the incoming data is RTP data. Firewalls typically operate by rejecting (i.e., discarding) incoming traffic which is destined for ports (either TCP or UDP) whose operational security is not known. Essentially, the firewall closes the ports for incoming traffic unless someone (e.g., the administrator of the firewall) can vouch that the destination port has a trusted program digesting the information. With RTP, the ports are ‘unspecified’, so the administrator could end up with having to open up many, or all of the UDP ports to allow the voice traffic to come in. While a field in the IP header of a UDP packet explicitly states that the following payload data is UDP payload data, there is no further identification in the UDP packet that the UDP payload data is RTP data. RTP data travels inside a UDP datagram as a payload of UDP. Since there is no tag or identifier in the incoming data packet itself that identifies the incoming data as RTP data, the destination must be informed that incoming data is RTP data. If the receiving system does not know that data coming in on a particular port is RTP data, then the receiving system usually discards such data. There are a few heuristics which can be applied to the RTP header to take a guess as to whether it is RTP. Routers use these heuristics to compress RTP headers, but their compression techniques, when inadvertently applied, are not destructive. However, the routers are only looking for compressible data and not looking at the data in order to route the data or identify the data as belonging to any particular call's media stream. The routers merely seek to exploit the compressible aspects of an RTP header, if in fact, there is such a header on a particular packet.